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Field of the Invention 

The present invention relates to network security and in particular to 
securing electronic identities during access attempts to services. 

Background of the Invention 
Preserving identity information in today's highly-connected computing 
environments is a challenging task. As electronic commerce becomes more and 
more pervasive, individuals are transmitting confidential information over the 
Internet with ever increasing frequency. As a result, identity theft has become 
commonplace, and organizations are continuously attempting to fill security holes 
as security lapses become apparent to them. 

Most techniques for preserving identity focus on preserving a sender's 
identity over an insecure network, such as the Internet. With these techniques, 
secure communications are often used with protocols such as Secure Sockets Layer 
(SSL). The primary concern of the industry has been to ensure that identity 
information is securely transmitted from a sender to a secure server. The 
assumption is that once identity information is safely and securely transmitted from 
a sender to a secure server, then confidentiality and security can be safely preserved. 
However, this assumes that the secure server is operating behind a firewall and that 
individuals with access behind that firewall are acting ethically and not attempting 
to comprise a sender's identity information. Unfortunately, organizations are 
learning that often security breaches are occurring within their own secure 
environments because not all employees of the organizations are trustworthy. 

The assumption is that security can be relaxed behind a secure firewall 
because outside intruders cannot comprise a sender's identity information within the 
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firewall. As a result, behind the firewall a sender's security information is 
frequently transmitted and placed on transmission lines with little or no security. 
Thus, the security information can be acquired with relative ease by malicious 
internal users working behind the firewall. 

For example, consider an organization offering several services over the 
Internet, where access to those services is externally controlled by a proxy server 
acting as a filtering proxy or as a secure authentication mechanism. These services 
may also include additional external subscription services which manage and 
provide access to the native service via the subscription services. A sender may use 
a World-Wide Web (WWW) browser to request access to a particular service 
behind the firewall. The request is transmitted with sender identity information over 
the Internet using a Hyper Text Mark-up Language having a Secure Sockets Layer 
protocol (HTTPS). The identity information permits the proxy server and the 
desired service to authenticate the sender for access to the service. The proxy server 
has access to the service via a secure network, such as an Intranet. Once the proxy 
server authenticates the sender, the sender's identity information and request are 
forwarded within the secure network to the desired service for servicing. 

During this forward process, the sender's identity information is vulnerable 
within the secure network and can be intercepted by individuals having access to the 
secure network. This means that the organization maintaining the services must rely 
on the integrity of its employees to prevent identity theft. In many situations this 
may be sufficient, but it only takes one misread or disgruntled employee to comprise 
a sender's integrity. Moreover, once identity theft has occurred, the damage to an 
organization's customer which results can cause irreparably injury to the 
organization's reputation and resources. 

Therefore, there exists a need for improved techniques that more securely 
distribute and manage electronic identities within a network. 

Summary of the Invention 

In various embodiments of this invention, novel techniques for generating 

and managing temporarily assigned identity information are taught. Requests for 
services are authenticated using identity information associated with the requests. 
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Configuration identity information is generated based in part on the identity 
information. The configuration identity information is further used for generating 
temporarily assigned identity information. The temporarily assigned identity 
information is updated to a protected identity directory (can also be an identity data 
5 store). Next, the temporarily assigned identity information and the requests are sent 
to the services on behalf of the requestors. The services access the protected 
identity directory with the temporarily assigned identity information for purpose of 
authenticating the requests. The temporarily assigned identity information is 
associated with the authenticated identity, and the services use the temporarily 
1 0 assigned identity information as if it were the authenticated identity. There are no 
changes to the services which are required to use the temporarily assigned identity 
information. 

More specifically and in one embodiment of the invention, a method for 
generating temporarily assigned identity information is presented. Identity 

15 information is authenticated. The identity information is associated with a request 
that is received from a requestor who desires access to a service. Temporarily 
assigned identity information is generated for the requestor. The temporarily 
assigned identity information is updated to a protected identity directory. Next, the 
request and the temporarily assigned identity information are transmitted to the 

20 service on behalf of the requestor. The service accesses the protected identity 
directory with the temporarily assigned identity information for authenticating the 
requestor for access. 

In another embodiment of the present invention, another method for 
generating temporarily assigned identity information is provided. A request for a 
25 service is acquired and authenticated. An identity configuration for the request is 
compiled. Moreover, temporarily assigned identity information is generated for the 
request using the identity configuration. The temporarily assigned identity 
information and the request are transmitted to the service. 

In still another embodiment of the present invention, an identity information 
30 management system is described. The identity information management system 
includes a proxy server, a local identity mapping store, and a protected identity 
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directory. The proxy server intercepts requests made for services, where the 
requests are associated with requestors. The local identity mapping store houses 
mappings between temporarily assigned identity information and identity 
configurations, both of which are generated by the proxy server from identity 
information provided with the requests. The proxy server updates the protected 
identity directory with the temporarily assigned identity information, and the proxy 
server transmits the temporarily assigned identity information and the requests to 
the services. The services use the temporarily assigned identity information for 
accessing the protected identity directory in order to authenticate the requests. 

In yet another embodiment of the present invention, a data store is provided 
for managing identity information. The data store includes identity configuration 
information, temporarily assigned identity information, and a mapping. A proxy 
server generates the identity configuration information in response to a request 
made from a requestor for a service. Further, the proxy server generates the 
temporarily assigned identity information using at least a portion of the identity 
configuration. The mapping links the identity configuration with the temporarily 
assigned identity information. The proxy server accesses the mapping for 
transmitting the temporarily assigned identity information along with the request to 
the service on behalf of the requestor. 

Brief Description of the Drawings 
FIG. 1 is a flowchart representing a method for generating temporarily 

assigned identity information; 
FIG. 2 is a flowchart representing another method for generating 

temporarily assigned identity information; 
FIG. 3 is a diagram of an identity information management system; and 

FIG. 4 is a diagram of an identity information data store. 

Detailed Description of the Invention 
In the following description, reference is made to the accompanying 
drawings that form a part hereof, and in which is shown by way of illustration 
specific embodiments in which the invention may be practiced. These embodiments 
are described in sufficient detail to enable one of ordinary skill in the art to practice 
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the invention, and it is to be understood that other embodiments may be utilized and 
that structural, logical, optical, and electrical changes may be made without 
departing from the scope of this invention. The following description is, therefore, 
not to be taken in a limited sense, and the scope of the invention is defined by the 
5 appended claims. 

As used herein a "sender" and "requestor" are used synonymously with one 
another. A requestor can be an end-user or an automated service that issues an 
electronic request for a service over a network. As an example, a requestor can be 
an end-user accessing a World-Wide Web (WWW) browser to activate links 
1 0 associated with an existing service. Furthermore, access to the service requires 

authentication, therefore the request includes identity information for the requestor. 
Identity information includes electronic data that is typically used for authenticating 
a requestor. Identity information can include electronic identifications (e.g., user 
identity, application identity), electronic passwords, digital certificates, encrypted 
1 5 tokens, biometric data, digital signatures, hardware values, network values, time of 
day values, calendar values, and the like. 

The identity information, if compromised, can be used to acquire a variety of 
other confidential information associated with a requestor, such as Social Security 
Numbers (SSNs), password hints, credit card numbers, bank account numbers, 
20 home address, phone numbers, and the like. This is so because once the electronic 
identity of the requestor is compromised other services that use the electronic 
identity can be accessed to acquire the additional confidential information. The 
other services have no way of distinguishing between a legitimate request made by a 
legitimate requestor from an illegitimate request made from a bogus requestor 
25 because the services authenticate requests using the identity information of the 
requestors. Thus, if the identity information is compromised all confidential 
information associated with that requestor's identity is potentially compromised. 

As used herein a "service" can include any electronic application, collection 
of applications, or systems that operate within a secure network behind a firewall. 
30 Access to the service requires identity information for a requestor; the identity 
information is used to authenticate a request or requestor for accessing the service. 
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A requestor indirectly issues requests to the service through an additional service, 
such as a proxy server acting as a firewall. Moreover, the service has access to one 
or more protected identity directories that permit the service to use any received 
identity information to properly authenticate a request or requestor. The protected 
5 identity directory is accessible to the service, the proxy server, or other services 
within the secure network. Moreover, the protected identity directory can be one or 
more directories interfaced together, one or more data stores interfaced together, or 
a combination of directories and data stores interfaced together. 

In one embodiment of the invention, the techniques presented herein for 
1 0 securing electronic identities are at least partially implemented within an identity 
proxy server, such as iChain or Excelerator, distributed by Novell, Inc. of Provo, 
Utah. The proxy server acts as a firewall to desired services and accepts requests 
originating from an insecure network for those services. With the teachings of this 
invention, there is no need to make modifications to any of the services; rather, the 
1 5 proxy server manages identity information associated with requests that are made 
for those services. Correspondingly, any legacy or existing services that requires 
identity information for authenticating requests can benefit and easily integrate with 
the techniques presented herein. 

FIG. 1 is a flowchart representing one method 100 for generating 
20 temporarily assigned identity information. The processing of the method 1 00 is 
implemented in a computer accessible medium, and in one embodiment is 
implemented as one or more services processing on a proxy server. Further, the 
proxy server acts as a firewall for a secure network. 

Initially, a requestor makes a request for a service via an insecure network. 
25 The service is accessible from within a secure network; however, the service does 
not directly receive the request from an insecure network. In other words, the 
request originates from an insecure network, such as the Internet, and the request is 
acquired by the processing of the method 100 and preprocessed in the manner 
described below before it is properly processed by the service. Moreover, the 
30 request includes identity information associated with the requestor. The identity 
information can include a password, an electronic identification for the requestor, a 
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certificate, a signature, a token, a hardware value, a network value (configuration 
value), a time of day value, a calendar value, a biometric value, or other values that 
may be used to authenticate an identity of the requestor. Moreover, the identity 
information can include a combination of one or more of the values described 
above. 

Accordingly, at 1 10, the processing of the method 100 acquires a request for 
a desired service and strips out the identity information; the identity information is 
used for authenticating an identity of the requestor, which will thereby authenticate 
the request and the requestor. If the request is properly authenticated, then, 
optionally, at 1 1 1, an aggregate identity configuration for the requestor is 
assembled. Acquisition of the request can occur by the desired service transmitting 
the request to the processing of the method 100. Alternatively, acquisition of the 
request can occur by a service or proxy that authenticates the identity of the 
requestor on behalf of the desired service by intercepting the request, or by 
otherwise acting as an intermediary between the requestor and the desired service. 

In one embodiment, the aggregate identity configuration is formed as an 
electronic identity object for the requestor from an authoritative identity store and an 
identity configuration policy specification. The authoritative identity store permits 
the processing of the method 100 to authenticate the requestor (i.e., identity of the 
requestor) and acquire other identity information about the requestor. The identity 
configuration policy specification defines available policies and attributes associated 
with the requestor's access levels and permissions within the secure network. These 
policies and attributes form an aggregated identity configuration for the requestor. 
Some of these policies and attributes may be germane to the request being processed 
and some can be germane to other requests that the requestor may make at some 
future point in time. The aggregate identity configuration forms an electronic 
identity object for the requestor within the secure network. Furthermore, in some 
embodiments, there can be more than one authoritative identity store which is used 
by the processing of the method 100 in forming the requestor's electronic identity 
object. Additionally, some additional information about the requestor can be 
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acquired from the requestor's computing environment and aggregated within the 
identity configuration. 

At 120, temporarily assigned identity information is generated for use with 
the received request and the requestor. The temporarily assigned identity 
information conforms to syntaxes and semantics that are expected by the desired 
service. The temporarily assigned identity information is used to impersonate the 
requestor during proxy and service interactions. Moreover, the temporarily assigned 
identity information is unique to a particular request, but the memory or storage that 
it occupies can be recycled for other requests and requestors, when a particular 
request that is being processed in the secure network expires. This is advantageous, 
because creating new storage locations within data stores (if any are used) can be 
expensive in terms of processing delay needed to re-create storage locations. 
Additionally, clean-up operations would typically need to be processed to free up 
storage previously occupied by no longer active temporarily assigned identity 
information values. Thus, in some embodiments recycling or reusing the storage 
occupied by inactive temporarily assigned identity information values provides 
added benefits with the invention. 

Furthermore, the temporarily assigned identity information can be in whole 
or in part randomly generated. In other embodiments the temporarily assigned 
identity information is deterministically generated, such as by using memory 
addresses, hash values, table index values, or combinations of values that generate a 
key which is used for temporarily impersonating the requestor's identity. In still 
further embodiments, the temporarily assigned identity information can be a subset 
of the original identity information associated with the requestor, where the subset 
reflects only those portions of the original identity information which may be 
needed by the desired service in processing the request. 

In one embodiment, at 121, the temporarily assigned identity information, 
the originally received identity information, and the electronic identity object of the 
requestor are associated or mapped to one another. Further, at 122, this mapping is 
maintained in a local identity store which is accessible only to the processing of the 
method 100. In this way a plurality of temporarily assigned identity information can 
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be managed for a plurality of requests and requestors, where some requests are 
associated with the same requestor and other requests are associated with a different 
requester. Moreover, some requests can be made for purposes of accessing the 
same service or for purposes of accessing a different service located within the 
secure network. In still other embodiments the mapping can also be temporarily 
housed within a cache accessible to the processing of the method 100. 

Additionally, in some embodiments, there are multiple local identity stores, 
where each local identity store is associated with the same or a separate processing 
instance of the method 100 within the secure network. In these embodiments, at 
123, the mappings can be synchronized with one another within the secure 
environment. 

Moreover, the temporarily assigned information or the electronic identity 
object(s) can be removed proactively by the processing of the method 100 at 124 
when a terminating event is detected. For example, the processing of the method 
100 can be configured such that when all outstanding requests for a particular user 
have been terminated then the mappings are deleted from the local identity store, the 
protected identity directory, and cache (as the case may be). 

As an example, suppose a particular requestor was issuing two requests from 
a single browser over the Internet for two separate services accessible within the 
secure network. Suppose further that the requestor terminates his browser and this 
event is detected by the processing of the method 100. In this situation, since the 
requestor has no active requests the mappings to temporarily assigned identity 
information are immediately removed from the local identity store and a protected 
identity directory, which is used by the services for authenticating the requests. In 
another example, suppose the requestor had two separate browsers processing, one 
browser for each separate request, and that the requestor terminates only one of the 
browsers. In this situation, the mapping for the requestor can remain unchanged and 
active within the local identity store and the protected identity directory. 

The previous example presupposes that a temporarily assigned identity 
information value is shared between two separate sessions (e.g., via the two 
browsers). Alternatively, if each browser uses a different temporarily assigned 
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identity information value for the requestor, which both map to the same 
authenticated identity of the requestor, then one of the different temporarily 
assigned identity information values can be removed from one of the local identity 
stores. 

Once the temporarily assigned identity information and the mapping to the 
requestor are generated, the temporarily assigned identity information is updated to 
a protected identity directory at 130. The protected identity directory can reside 
entirely within volatile storage (e.g., memory), reside entirely within non-volatile 
storage, or reside within a combination of volatile and non-volatile storages. 
Additionally, the protected identity directory can be one or more data stores, one or 
more directories, or a combination of data stores and directories synchronized with 
one another. 

In some embodiments, the electronic identity object created for the requestor 
is also updated to the protected identity directory. In other embodiments, only the 
temporarily assigned identity information is updated to the protected identity 
directory and associated with an existing requestor identity object. In some 
embodiments, there may be more than one protected identity directory that 
synchronize with one another, such that when one protected identity directory alters 
its identity information or temporarily assigned identity information for a requestor 
the modifications are communicated and synchronized with the other protected 
identity directories. Furthermore, in one embodiment, a first protected identity 
directory may house only the temporarily assigned identity information while a 
second protected identity directory house the original identity information 
associated with the temporarily assigned identity information. In these 
embodiments, access to the first protected identity directory with the temporarily 
assigned identity information can be augmented with the mappings to access the 
original identity information housed in the second protected identity directory. 

The service associated with the original request and the processing of the 
method 100 are the entities that can access the protected identity directory. The 
service accesses the protected identity directory for purposes of authenticating a 
request or requestor (i.e., identity of the requestor) for access. The processing of the 
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method 100 accesses the protected identity directory for purposes of linking the 
requestor (requestor identity object) with the temporarily assigned identity 
information. 

In one embodiment, the temporarily assigned identity information is a 
temporarily assigned and temporary password associated with an electronic 
identification for the requestor. In other embodiments, the temporarily assigned 
identity information is a temporarily assigned electronic identification and password 
associated with the requestor. Moreover, in some embodiments, the protected 
identity directory can be configured to send events when dynamic changes are made 
to identity information associated with the requestor. In these situations, at 131, the 
temporarily assigned identity information, the electronic identity object, and the 
mapping can be automatically adjusted as needed by the processing of the method 
100. Moreover, in some embodiments, the detected changes to the identity 
information can be automatically updated to one or more authoritative identity 
stores or logged such that the changes can be subsequently updated to one or more 
authoritative identity stores. 

Next, the processing of the method 100, at 140, transmits the temporarily 
assigned identity information and the originally received request to the service. 
This transmission occurs when the desired service asks for requestor authentication. 
The service uses the temporarily assigned identity information for authenticating the 
request or the requestor for access to that service via the protected identity directory. 
In doing this, the service accesses the protected identity directory with the 
temporarily assigned identity information to acquire the requestor's electronic 
access policies and attributes. In some cases the processing of the method 100 
generates these policies and attributes as an electronic identity object (aggregate 
identity configuration) and updates them to the protected identity directory with the 
temporarily assigned identity information. In other cases, these policies and 
attributes are pre-existing within the protected identity directory and embodied as a 
requestor access object (requestor identity configuration). 

In some embodiments, the original provided identity information and the 
temporarily assigned generated identity information are all that is needed by the 
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processing of the method 100 to secure the identity of the requestor. In these 
embodiments, the mapping housed in the local identity store includes the association 
between the identity information and the temporarily assigned identity information, 
the protected identity directory is updated with the association such that when the 
service provides the temporarily assigned identity information to the protected 
identity directory it is accepted as if it were the original identity information that 
was provided with the request from the requestor. Thus, in some embodiments, 
there is no need to manage aggregate identity configurations (electronic identity 
objects) for the requestor and those identity configurations can be managed with 
pre-existing techniques. 

The service cannot authenticate a request without the temporarily assigned 
identity information, and the processing of the method 100 controls the generation 
and termination of the temporarily assigned identity information. In this way, any 
malicious user located within the secure network can only acquire the temporarily 
assigned identity information, but this information is temporary and wholly 
controlled by the processing of the method 100. Thus, malicious users will find that 
the intercepted temporarily assigned identity information has a severely 
circumscribed use, which is specific to only one service. Moreover, the service that 
consumes the temporarily assigned identity information may be configured to detect 
and deny multiple login events. Thus, malicious users will find that the temporarily 
assigned identity information is nearly useless to them and in some instances 
entirely useless to them. In this way, confidential information associated with a 
requestor is more securely managed and transmitted within a secure network, since 
a requestor's identity information is not transmitted to the service within the secure 
network; rather only temporarily assigned and temporary identity information is 
transmitted to the service. 

FIG. 2 is a flowchart representing another method 200 for generating 
temporarily assigned identity information. The processing of the method 200 is 
implemented and accessible from a computer-accessible medium. In one 
embodiment, the processing of the method 200 is implemented as one or more 
services within a proxy server. 
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Initially, a request for a service is acquired at 210. The request includes 
identity information associated with a requestor of the request. In one embodiment, 
the request originates from a service over an insecure network at 2 1 1 . For example, 
an end-user (requestor) uses a WWW browser (browser service) to activate a 
Uniform Resource Locator (URL) link within a browser page. The URL link is a 
request for a service located within a secure network, and when accessed cookies 
that are associated with the requestor are attached to the request and transmitted 
over the Internet (insecure network). A proxy server that proxies for the service and 
that embodies the processing of the method 200 intercepts the request and performs 
the processing described below. 

Initially, the request is parsed to obtain the identity information associated 
with the requestor of the request. At 220, that identity information is used for 
authenticating the request (i.e., via authenticating an identity of the requestor) for 
access to the secure network and ultimately the desired service associated with the 
request. This can be achieved by using the identity information to access one or 
more authoritative data stores. Once the request and requestor are authenticated, 
then access policies and attributes associated with the requestor are obtainable. 

Accordingly, at 230, an identity configuration for the requestor is compiled 
at 230. This identity configuration can be an aggregate access configuration based 
on aggregating identity policies and attributes that are available from the one or 
more authoritative identity stores, as depicted at 231. In some additional 
embodiments, the identity configuration can also include additional information 
about the requestor that is obtained from the requestor's computing environments, 
such as hardware configuration, network configuration, or other personal 
information that may be accessible to the processing of the method 200 (e.g., via 
cookies and the like). The identity configuration serves as an electronic identity 
object for the requestor associated with the request. 

At 240, temporarily assigned identity information is generated for the 
request. The temporarily assigned identity information is a temporary identification 
and password, or a temporary password that is supplied to the desired service to 
process the initially acquired request. The storage space associated with temporarily 
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assigned identity information can be recycled and used with other requests, at 241. 
Temporarily assigned identity information can be forced to expire based on 
detection of event that indicates a particular requestor is not longer logged into or in 
communication with the processing of the method 200. 

The identity configuration and the temporarily assigned identity information 
are updated to a protected identity directory. The desired services access the 
protected identity directory when a request is received for purposes of 
authenticating the request or requestor (i.e., true identity of requestor) and for 
purposes of acquiring the appropriate access policies and attributes that are to be 
given to the requestor. In one embodiment, only the mapping between the 
temporarily assigned identity information and the original received identity 
information are updated to the protected identity directory. In these embodiments, 
the access policies and attributes associated with the requestor need not be managed 
by the processing of the method 200. 

Once the protected identity directory is updated, at 250, the request and the 
temporarily assigned identity information is transmitted to the desired service for 
processing. In one embodiment, the transmission occurs via a secure network at 
25 1 . Moreover, at this time, should any malicious user attempt to compromise the 
electronic identity of the requestor, all that is available to the malicious user is the 
temporarily assigned identity information, since the original provided identity 
information remains secure and is not placed on the wire within the network, such 
that it may be compromised. This is a significant improvement over conventional 
techniques that rely on the integrity of users within the secure network to maintain 
the secrecy of a requestor's electronic identity. 

In still other embodiments, the method 200 can be processed for multiple 
iterations associated with additional requests for services from the same requestor, 
as depicted at 252. In this way, a requestor can issue multiple requests for disparate 
services that are accessed via the secure network. In such embodiments, the new 
requests are authenticated and it is determined that an existing authenticated request 
already exists and includes temporarily assigned identity information. Thus, the 
new request is associated with the existing temporarily assigned identity information 
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and no update to the protected identity directory need occur. The new request is 
associated with the temporarily assigned identity information and transmitted to the 
new service that is being requested. 

At 260, the service that receives the request and the temporarily assigned 
identity information accesses the protected identity directory for purposes of 
authenticating the request or requestor and for purposes of acquiring the appropriate 
access policies and attributes associated with the requestor of the request. In some 
embodiments, the appropriate access policies and attributes are defined in the 
compiled identity configuration that was aggregated by the processing of the 
method 200. In other embodiments, the appropriate access policies and attributes 
are pre-existing within the protected identity directory but uniquely associated with 
the temporarily assigned identity information which was updated by the processing 
of the method 200. 

The embodiments of the method 200 eliminate the need to transmit a 
requestor's electronic identity information within a secure network, where such 
information may be compromised by a malicious user that has legitimate or 
illegitimate access to the secure network. Furthermore, the embodiments of the 
method 200 permit temporarily assigned identity information to be temporary for 
improved security, and the temporarily assigned identity information can be 
recycled within the secure network. 

It should also be noted that in some embodiments, the period during which 
temporarily assigned identity information can remain valid for processing iterations 
of the method 200 can be configurable. That is, rules can be selectively 
implemented for determining when and if temporarily assigned identity information 
is removed from the protected directory store. Moreover, in some embodiments, the 
temporarily assigned identity information can be replicated within one or more 
directories from the protected identity on a temporary basis. This replication and 
removal can also be configured based on the desired needs of the network. 

FIG. 3 is a diagram of an identity information management system 300. The 
identity information management system 300 is implemented in a computer- 
accessible medium and is accessible from insecure networks and further includes a 

Attorney Docket No.: 1565.057US1 15 
Client Docket No.: IDR-655 



portion of processing and services that reside in a secure network. In one 
embodiment, the identity information management system 300 serves as a firewall 
or other secure authentication mechanism for a secure network. 

The identity information management system 300 includes at least one proxy 
server 301, at least one local identity mapping store 302, and a protected identity 
directory 303. The proxy server 301 is accessible to a service 310 that is accessible 
over an insecure network. 

During operation of the identity information management system 300, a 
service 310 issues a request via the insecure network via communication line Al. In 
some embodiments, A 1 is an HTTPS communication originated from a service 310 
that is a WWW browser over an insecure network which is the Internet. The request 
is directed to a service 304 located within the secure network. Moreover, the 
request can directly or indirectly include identity information associated with the 
requestor of the request. The identity information can include an electronic 
identification (e.g., user identity or application identity), a password, a certificate, a 
token, a hardware value, a network configuration value, a time of day value, a 
calendar value, a biometric value, or a combination of the above-mentioned values 
that permits the service 304 and the proxy server 301 to authenticate the request or 
requestor (i.e. identity of the requestor) for access to the service 304. 

Access to the service 304 can only be made via Al, such that the proxy 
server 301 effectively intercepts the request on behalf of the requestor and then 
processes the request within the secure environment to the service 304. When the 
request is initially intercepted, the identity information is authenticated and an 
identity configuration specification 306 and one or more authoritative identity stores 
305 are consulted via communication links B and C, respectively, for purposes of 
aggregating an identity configuration for the requestor of the request. The identity 
configuration includes access policies and attributes that are permissible for the 
requestor within the secure environment. 

Once the identity configuration is aggregated or compiled, the proxy server 
301 or another service generates temporarily assigned identity information for the 
request and requestor. The temporarily assigned identity information and the 
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identity configuration are associated with one another within a local identity 
mapping store 302 via communication link Dl. In one embodiment, and for 
purposes of improved security, the local identity mapping store 302 is only 
accessible only to the proxy server 301 . In another embodiment, copies of the 
temporarily assigned identity information and the identity configuration are 
maintained and managed in a cache accessible to the system 300. 

Next, the proxy server 301 or another service updates the protected identity 
directory 303 via communication link E with the identity configuration and the 
temporarily assigned identity information. Then, when the desired service 304 
indicates that it needs to authenticate the requestor, the proxy server 301 transmits 
the temporarily assigned identity information to the desired service 304 via 
communication link F. In another embodiment, the original intercepted request and 
the temporarily assigned identity information are sent by the proxy server 304 via 
communication link F to the service before the desired service 304 indicates that it 
needs to authenticate the requestor for a request. Upon receiving the temporarily 
assigned identity information, the service 304 accesses the protected identity 
directory 303 via communication link G, where the temporarily assigned identity 
information authenticates the request and access is granted to the service 304, where 
the access conforms to the access policies and attributes that are defined in the 
identity configuration. 

In alternative embodiments, the proxy server 301 or another service does not 
need to aggregate identity configurations; rather, the proxy server 301 or other 
service associates the temporarily assigned information with the originally provided 
identity information supplied with the original request in the local identity mapping 
store 302. Then, via E this mapping is updated in the protected identity directory 
303, such that when the service 304 attempts to authenticate the request via G, the 
temporarily assigned identity information automatically translates as if it were the 
identity information and access policies and attributes are properly acquired by the 
service 304 from the protected identity directory 303. 

Additionally, proxy server 301 or a managing service manages the 
temporarily assigned identity information, the identity configurations, and the 
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associated mappings within the secure network. In this way, the proxy server 301 or 
managing service can remove this information when it determines that removal is 
necessary. For example, perhaps a requestor no longer has any valid session with 
the proxy server 301, indicating that the temporarily assigned identity information, 
5 the identity configuration, and the mapping associated with the requestor should be 
removed from the local identity mapping store 302 and the protected identity 
directory 303. 

Additionally, the proxy server 301 or managing service can manage the 
temporarily assigned identity information, so that storage locations used for housing 

10 the temporarily assigned identity information can be recycled for other requests or 
even other requestors. This permits active and dynamic storage management of the 
protected identity directory 303 and the local identity store 302. 

The identity information management system 300 is not limited in operation 
to a single proxy server 301 or a single local identity mapping store 302. In this 

15 way, the system 300 can cooperate with additional proxy servers, such as proxy 
server 301 A (or for that matter any additional service). During operation of the 
system 300, proxy server 301 A receives a request from a different service 31 OA via 
communication link A2, the request again originates over an insecure network. 
Proxy server 301 A communicates directly with proxy server 301 via link Z. 

20 Proxy server 301 A operates and processes the received request in a similar 

mariner discussed above with proxy server 301; however, local identity mapping 
store 3 02 A is synchronized to local identity mapping store 302 via communication 
link D3. In this way, mappings associated with temporarily assigned identity 
information and identity configurations are synchronized, such that changes made 

25 by one proxy server 301 Or 301 A are available within both local identity mapping 
stores 302 and 302A. 

In another mode of operation, the proxy server 301 A looks up the requestor 
in the protected identity directory 303 to determine if the requestor is already 
authenticated and if any such authentication is still valid (e.g., not expired or stale). 

30 If these conditions are met, then the proxy server 301 A uses the protected identity 

Attorney Docket No.: 1565.057US1 18 
Client Docket No.: IDR-655 



directory 303 to automatically authenticate the requestor to the desired service 
304A. 

In still another mode of operation, the proxy server 301 A can update a 
second protected identity directory (not shown in FIG. 3) with the temporarily 
5 assigned identity information housed in the protected identity directory 303. This 
may be desirable in situations where the desired service 3 04 A is designed to use the 
second protected identity directory and not the protected identity directory 303 
shown in FIG. 3. 

Like the description provided above, the proxy server 301 A uses 

10 communication link H to update, if necessary at all, mappings between temporarily 
assigned identity information and identity configurations within the protected 
identity directory 303. Next, the temporarily assigned identity information and the 
originally received request received from service 31 OA are transmitted via 
communication link I to service 304A. Again, this transmission can be delayed 

15 until the system 300 receives an authentication request for the requestor, where the 
authentication request is sent from the service 3 04 A. The service 3 04 A then uses 
communication link J to authenticate the request or requestor for access to the 
service using the provided temporarily assigned identity information. 

FIG. 4 is a diagram of one identity information data store 400 that resides in 

20 a computer-accessible medium and is accessed for purposes of acquiring mappings 
associated with identity information. 

The identity information data store 400 includes identity configuration 
information 401, temporarily assigned identity information 402 and a mapping 403. 
The identity configuration information 401 is an aggregated electronic 

25 representation of access policies and attributes associated with a requestor. A proxy 
server 410 or other managing service assembles and manages the identity 
configuration information 401 in response to receiving a request from a requestor 
for access to a service that resides within a secure network. Moreover, the proxy 
server 410 or managing service uses one or more authoritative identity stores and an 

30 identity configuration policy specification in assembling the identity configuration 
information 401. 
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The proxy server 410 or managing service also generates the temporarily 
assigned identity information 402 on behalf of a request associated with identity 
information for the requestor. The linkage between the identity configuration 
information 401 and the temporarily assigned identity information 402 is identified 
5 as a mapping 403. In another embodiment, one or more authoritative identity stores 
or other services that provide access to the authoritative identity stores supply the 
mapping 403. 

The proxy server 410 or managing service populates fields of the identity 
configuration information 401 and temporarily assigned identity information 402, 

10 and in response to this the data store 400 maintains and records a mapping for each 
populated pair of identity configuration information 401 and temporarily assigned 
identity information 402. This mapping permits the proxy server or managing 
service to acquire and manage the identity configuration information 401 and the 
temporarily assigned identity information 402. 

1 5 The proxy server 4 1 0 or managing service consumes the data store 400, in 

the following manner. A requestor sends a request via an insecure network and the 
proxy server 410 intercepts the request. The request includes, either directly or 
indirectly, identity information associated with the requestor. Moreover, the request 
is directed to a service that resides in a secure network being managed by the proxy 

20 server 4 1 0 or another managing service. The proxy server 4 1 0 or managing service 
first authenticates the requestor's identity information, and then the proxy server or 
managing service 410 assembles or compiles an identity configuration value for the 
requestor. The identity configuration value is an electronic object or representation 
of the requestor and its permitted access policies and attributes. 

25 The proxy server 4 1 0 or managing service queries the data store 400 with 

the identity configuration value to determine if it is pre-existing within the data 
store. If it is pre-existing then the proxy server 410 or managing service uses the 
associated mapping value included in the mapping field 403 of the data store 400 for 
purposes of acquiring a temporarily assigned identity information value from the 

30 associated temporarily assigned identity information field 402. Next, the proxy 
server 410 or managing service transmits the temporarily assigned identity 
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information value and the originally received request to the appropriate service that 
is needed for processing the request. In some embodiments, this transmission only 
occurs when the appropriate service indicates that it has a requestor which needs to 
be authenticated. 

5 If the identity configuration value does not pre-exist in the data store, then 

the proxy server 410 or managing service creates a new record instance in the data 
store 400. The new record instance includes an identity configuration value for the 
identity configuration information field, a temporarily assigned identity information 
value for the temporarily assigned identity field 402, and a mapping value that links 

10 the two fields within the record via the mapping field. The mapping value is 
automatically generated and maintained by the data store 400. In some 
embodiments, the new record instance is actually a recycled or reused storage 
record that was associated with previous and now expired, obliterated, purged, 
deleted, and expunged information. 

15 Next, the proxy server 410 or managing service updates the newly generated 

identity configuration information value and the temporarily assigned identity 
information value to a protected identity directory 420. Then, the proxy server 410 
or managing service transmits the original received request and the newly generated 
temporarily assigned identity information value to the needed service, where the 

20 service uses the temporarily assigned identity information value to access the 
protected identity directory 420 for purposes of authenticating the request or 
requestor and for purposes of acquiring the identity configuration information value. 
The identity configuration information value provides the access policies and 
attributes that are appropriate for the request or requestor. 

25 In some embodiments, more than one data store 400 participates in systems 

consuming the data stores 400. In each of these embodiments, a single data store 
400 is accessible to a single proxy server 410 or managing service; however, the 
data stores 400 are designed to stay in synchronization with one another via a 
separate and secure communication link that sends notifications of changes. An 

30 example system using more than one data store 400 is described above in detail with 
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the description of FIG. 3 and system 300. Thus, the data store 400 is not directly 
accessible by the services associated with the requests. 

Although specific embodiments have been illustrated and described herein, 
those of ordinary skill in the art will appreciate that any arrangement calculated to 

5 achieve the same purpose can be substituted for the specific embodiments shown. 
This disclosure is intended to cover all adaptations or variations of various 
embodiments of the invention. It is to be understood that the above description has 
been made in an illustrative fashion only. Combinations of the above embodiments, 
and other embodiments not specifically described herein will be apparent to one of 

10 ordinary skill in the art upon reviewing the above description. The scope of various 
embodiments of the invention includes any other services in which the above 
structures and methods are used. Therefore, the scope of various embodiments of 
the invention should be determined with reference to the appended claims, along 
with the full range of equivalents to which such claims are entitled. 

15 It is emphasized that the Abstract is provided to comply with 37 C.F.R. 

§ 1.72(b), which requires an Abstract that will allow the reader to quickly ascertain 
the nature and gist of the technical disclosure. It is submitted with the 
understanding that it will not be used to interpret or limit the scope or meaning of 
the claims. 

20 In the foregoing Detailed Description, various features are grouped together 

in single embodiments for the purpose of description. This method of disclosure is 
not to be interpreted as reflecting an intention that the claimed embodiments of the 
invention require more features than are expressly recited in each claim. Rather, as 
the following claims reflect, inventive subject matter lies in less than all features of 

25 a single disclosed embodiment. The following claims are hereby incorporated into 
the Detailed Description, with each claim standing on its own as a separate 
embodiment. 
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